在光桓資訊科技期間，估時方式是採用這篇: Scrum中的敏捷估計？故事點和計劃撲克所提到的方式，下去估計每張「Task 卡片」的合理完成時間。特別強調，當時的光桓資訊科技是已經以 Scrum 開發完成2個以上專案的成熟團隊。
不過當自己在之後的公司中，獨力帶領團隊發現這個方式並不適合在剛開始導入 Scrum 的開發團隊。
透過費比尼西(Fibonacci)卡牌來估時，最大的缺點在於一開始沒人知道自己能耗費多少時間來完成任務。因此估時都是直接丟出無限大的卡牌。最後都會由Scrum 導師(SM)訂出時間，又或者都先押每期衝刺活動(sprint)的最後一天。如同Day 8所提到的 :

之後，當成員提前完成當期卡片後，再不斷的補上後續要開發的「Task 卡片」。如同Day 11所提到的 :

過程中，在每期衝刺活動(sprint)最後一天 code review，所分享的開發技術文件，反而變成目前我在帶領團隊估時的最重要依據。

昨日提到的，為什麼需要最資淺的人員依據文件來實做一次 ?
關鍵就是要知道最資淺的人員看著文件完成任務的時間=MinTime。
以這個MinTime時間 x 1.5 倍是目前類似的卡片任務所允許的時間上限。
至於為什麼是 1.5 倍 ?

因為前人走過的路，不應該耗時到最資淺人員能完成時間的兩倍。多那 0.5 倍的緩衝期間，也會激勵成員坦白說明自己遭遇的困難。

Scrum 開發，最忌諱的就是成員總是報喜不報憂。

如何設計一套模式讓成員能坦誠地面對問題，不容易啊 !

不過目前觀察的結果，當開發文件越來越完整時，其實成員都是能在MinTime的時間內完成。
而且，非常有意思的現象是，由於要求每期 MVP 的「Task 卡片」都必需在衝刺活動(sprint)內完成，一般的卡片並不一定在每期的 code review 都能有開發技術文件。不過，MVP 的開發技術文件每期都會完整分享。

今日的結論就是 :

人類是需要適當的壓力才會成長。